Today most merchants, whether brick and mortar or Internet, accept electronic payments (e.g., credit cards, debit cards, gift cards) as tender for transactions. Electronic payments may also be accepted by vending machines, kiosks, automated tellers or other systems where a human is not needed to conduct the transaction or process an electronic payment as tender for the transaction.
FIG. 1 illustrates an example architecture used to process electronic payments for merchant transactions. The architecture includes a merchant system 110, a payment handler 120, a communication network 130, and a payment processing system 140. The merchant system 110 may be a hardware system (e.g., electronic cash register (ECR), point of sale (POS)) or may be a software system (e.g., POS). The merchant system 110 may track items purchased and generate an invoice/sales receipt based on the cost of those items purchased and any taxes and/or discounts applied. The merchant system 110 may include an interface for gathering data about purchased items. The interface may include, but is not limited to, a scanner to scan codes associated with items (e.g., UPC codes), a keyboard to enter data associated with items, or a touch screen to select items. The merchant system 110 may be tied to other systems (e.g., inventory system, management system). The merchant system 110 may also include an interface to gather electronic payment information (e.g., card number). The interface may include, but is not limited to, a card reader (swiper), a scanner, a keyboard, or a touch screen.
The payment handler 120 may process the electronic payment information and purchase transaction data (e.g., payment amount) to create electronic payment transactions and communicate the electronic payment transactions to the payment processing system 140. The payment handler 120 may be separate from the merchant system 110, interfaced to the merchant system 110 or integrated into the merchant system 110. The payment handler 120 may receive the payment amount from the merchant system 110 or the payment amount may be entered into payment handler 120. The payment handler 120 may receive the electronic payment information from the merchant system 110 or an electronic payment information device (not illustrated) connected to the payment handler 120, or the electronic payment information may be entered into payment handler 120. The payment handler 120 may include an interface to gather the electronic payment information. The interface may include, but is not limited to, a card reader, a scanner, a keyboard, or a touch screen.
The payment handler 120 may be configured to operate with a specific payment processing system 140 (create electronic payment transactions in format required). The payment handler 120 may also be configured for a specific merchant-payment processor relationship (merchant account). The configuration of the payment handler 120 is discussed in more detail later.
The communication network 130 provides communications between the payment handler 120 and the payment processing system 140. The communication network 130 may be a phone network, the Internet and/or a wireless network.
The payment processing system 140 receives and processes the electronic payment transactions from the payment handler 120. The electronic payment transactions received may include information related to the transaction (e.g., payment amount), information related to the electronic payment used (e.g., card number), and information related to the merchant (e.g., merchant identifying information). The payment processing system 140 may determine if the electronic payment transaction received is authorized for the merchant (e.g., does merchant accept that type of credit card) and can be processed (e.g., is transaction amount within card limit of the purchaser). Once the transaction is authorized/approved, the payment processing system 140 may process payment from the card company to the merchant based on identification of the merchant included in the electronic payment transaction.
FIGS. 2A-2C illustrate several example merchant system-payment handler architectures. FIG. 2A illustrates an architecture where the merchant system 110 and the payment handler 120 are separate devices that are not interfaced together or communicating directly with one another. The merchant system 110 does not communicate payment amount to the payment handler 120 so the payment amount needs to be entered (manually) into the payment handler 120. The payment handler 120 may include a user interface (e.g., keyboard) for entering the payment amount. Additionally, cross referencing may be required between the purchases processed in the merchant system 110 and the electronic payment transactions processed in the payment handler 120. The payment handler 120 may include an electronic payment interface (e.g., card reader, scanner, keyboard) for accepting data related to the consumer and their electronic payment (e.g., credit card number). The payment handler 120 is used as a data terminal to enter payment amount and electronic payment information.
FIG. 2B illustrates an architecture where the merchant system 110 and the payment handler 120 are separate devices that are interfaced together and communicate therebetween. The merchant system 110 provides the payment amount to the payment handler 120. The merchant system 110 may include an electronic payment interface for accepting electronic payment information and may provide the electronic payment information to the payment handler 120.
FIG. 2C illustrates an architecture where the merchant system 110 and the payment handler 120 are integrated into a single device. The payment handler 120 may be software, hardware or firmware within the merchant system 110. The payment handler 120 may receive the payment amount from the merchant system 110. The merchant system 110 may include an electronic payment interface for accepting electronic payment information and may provide the electronic payment information to the payment handler 120.
When a merchant and a payment processing system 140 (payment processor) execute an agreement for the payment processor to handle electronic payment transactions for the merchant the payment processor creates a merchant account for the merchant that identifies the merchant and defines parameters associated with the merchant agreement. The merchant account may define the types of transactions authorized and include various identifications (e.g., merchant ID, payment processor ID, merchant account ID). The merchant account may be stored in the payment processing system 140. The payment processing system 140 may utilize the p merchant account to identify incoming electronic payment transactions with the merchant, validate the electronic transactions, and process the electronic payment transactions according to the merchant agreement. The payment processing system 140 may require the incoming electronic payment transactions to be a certain format and contain certain data from the merchant account in order to identify, validate and process the electronic payment transactions.
Regardless of the type of payment handler 120 used, in order for the electronic payment transactions to be processed the payment handler 120 needs to be configured in order to communicate with the payment processing system 140. The configuration of the payment handler 120 may include defining the format of electronic payment transactions required by the payment processing system 140. The payment handler 120 may include software (processor application) that defines the electronic payment transaction format required by the payment processing system 140 that will be processing the electronic payment transactions for the merchant. The payment handler 120 provided to the merchant may have the appropriate processor application loaded for the payment processing system 140.
In addition, the payment handler 120 may include a profile that defines parameters regarding the merchant agreement (merchant profile) stored therein. The merchant profile may be similar to the merchant account, and the two may contain at least a portion of the same data. The merchant profile may contain data that is required in the electronic payment transaction format for the associated payment processing center 140. The payment handler 120 may create the electronic payment transaction based on the processor application, the merchant profile, and the payment amount.
Referring back to FIG. 1, the merchant profile may be created by a configuration system 150. The configuration system 150 may receive data about an established merchant account from the payment processing system 140 and create the merchant profile therefrom. The configuration system 150 may also maintain processor applications used by the payment handlers 120 to create the electronic payment transactions for each of the payment processing systems 140. The merchant profile may be created to work with a specific processor application.
The installation and configuration of the payment handler 120 at a merchant location requires that the appropriate processor application and the merchant profile be loaded therein, which is usually too complicated for the typical merchant. Accordingly, vendors are typically utilized to install and configure the payment handlers 120 for merchants. The vendors may be associated with the payment processing systems 140 or may be independent therefrom. The vendors need to obtain an appropriate payment handler 120 having an appropriate processor application loaded thereon. The vendors need to coordinate with the configuration system 150 in order to ensure the merchant profile is created (can not proceed with installation until the client profile is created by the configuration system 150).
The vendors may obtain the merchant profile from the configuration system 150 by programming the payment handler 120 to request a merchant profile for the specific merchant agreement (the request may need to include multiple identifications associated therewith, such as, merchant ID and merchant agreement ID). The vendors may alternatively obtain the merchant profile by contacting the configuration system 150 directly (e.g., via phone, fax, email) and requesting a download. The vendors may obtain/load the merchant profile prior to arriving at the merchant location to install the payment handler 120 or may obtain/load the merchant profile at the time of installation from the merchant location. The installation of the payment handler 120 includes connecting to merchant system 110 and the communication network 130.
Once the payment handler 120 is installed and configured, an electronic payment transaction may be processed to ensure it is processed correctly. Any errors in the processing of the electronic payment transaction require troubleshooting and may require communications between at least some subset of the vendor, the configuration system 150, the payment processing system 140, and the merchant. The troubleshooting may determine, for example, that the merchant profile created has errors and require the configuration system 150 to recreate the merchant profile, may determine that the merchant profile was loaded incorrectly or the wrong merchant profile was loaded and require the merchant profile to be reloaded, or may determine that the processor application was loaded incorrectly or the wrong processor application was loaded and require the processor application be made available to the vendor for download. The delivery, installation, configuration and validation of the payment handler 120 is a significant cost factor in deploying a new merchant account.
Furthermore, if the merchant profile or the processor application becomes corrupt the payment handler 120 may need to be reconfigured. Additionally, if attributes related to the merchant account change (e.g., allow additional transactions) the payment handler 120 may need to be reconfigured. Moreover, if the payment processing system 140 is modified (e.g., data required or format of electronic payment transaction changes, payment processing system 140 contact information (e.g., IP address) changes) the payment handler 120 may need to be reconfigured. The reconfiguration of the payment handler 120 may require the vendor to return for reconfiguration thereof, the payment handler 120 to be returned for reconfiguration, or replaced with a unit that has been reconfigured. Alternatively, the merchant may be provided with instructions that enables them connect to the configuration server 150 in order to download the merchant profile and/or processor application from the configuration system 150. Regardless of the form of reconfiguration utilized, it may result in delays and additional costs.
The payment handlers are typically not tracked and/or associated with merchants. Accordingly, vendors or other parties that have an account with the configuration system 150 and know how to configure a payment handler 120 can establish communication with the configuration system 150 and have a merchant profile associated with a particular merchant loaded on any payment handler 120 having the appropriate processor software loaded thereon (merchant need not purchase or rent payment handler 120). Furthermore, vendors or other parties could establish communication with the configuration system 150 and arrange to have a processor application associated with a merchant account downloaded onto payment handlers not originally associated with that payment processor. The coordination with the configuration system 150 to download merchant profiles and/or processor applications associated with a merchant account enables a payment handler 120 to be reused by the same merchant for different merchant agreements or to be used by different merchants. The reprogramming of the payment handlers 120 creates an aftermarket for the devices that is out of the control of the payment processors or equipment manufactures. The aftermarket reduces the amount of payment handlers 120 required for new merchant accounts and thus reduces the profits the payment processors or equipment manufactures can make by charging for the devices as part of the merchant contract.
What is needed is a way to simplify/expedite the creation of the merchant profile, simplify the configuration/reconfiguration of the payment handlers 120, and control the merchant profiles and processor applications that can be loaded onto payment handlers 120 in order to control use thereof.